Method and device for filling video ad requests with video ad content transcoded in real time to a stream at a temporary url

ABSTRACT

The technology disclosed relates to filling video ad requests with video ad content that begins in a format incompatible with the mobile device that is requesting the ad content. In particular, it relates to accessing available on ad content, transcoding the ad content to a video stream and publishing the video stream to the mobile device that requested the head content. This sometimes requires synchronization between a player on the mobile device and the video stream transcoder.

CROSS-REFERENCE

This application is a continuation of U.S. application Ser. No.13/843,151, titled “Method and Device for Filling Video Ad Requests withVideo Ad Content Transcoded in Real Time to a Stream at a TemporaryURL”, filed 15 Mar. 2013 (Atty Docket No. MEFE 1004-1). The priorityapplication is incorporated by reference herein for all purposes.

BACKGROUND Field

The technology disclosed relates to filling video ad requests with videoad content that begins in a format incompatible with the mobile devicethat is requesting the ad content. In particular, it relates toaccessing available ad content, transcoding the ad content to a videostream and publishing the video stream to the mobile device thatrequested the ad content. This sometimes requires synchronizationbetween a player on the mobile device and the video stream transcoder.

Related Art

Animated and video advertising to desktop computers was popularized byAdobe with the Flash format. However, a number of companies decided thatthe Flash format required too much computing to be practical for mobiledevices.

A great deal of ad content remains available primarily in FLV format. Adservers and ad exchanges routinely respond to fill requests for video adcontent with URLs to FLV formatted content. More generally, as mobiledevices evolve and devices such as TVs, set-top boxes and DVD playersbecome connected to the Internet, there will be mismatches between theformat of advertising content and the display capabilities of thesedevices.

It is desirable to provide a platform for filling video ad requests withvideo ad content that begins in a format incompatible with therequesting device.

SUMMARY

The technology disclosed relates to filling video ad requests with videoad content that begins in a format incompatible with the mobile devicethat is requesting the ad content. In particular, it relates toaccessing available ad content, transcoding the ad content to a videostream and publishing the video stream to the mobile device thatrequested the ad content. This sometimes requires synchronizationbetween a player on the mobile device and the video stream transcoder.Other aspects and advantages of the technology disclosed can be seen onreview of the drawings, the detailed description and the claims, whichfollow.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level a block diagram of an example environment inwhich an ad mediation server adapts video ads from an incompatibleformat to one that run satisfactorily on a requesting device

FIG. 2 is a sample Digital Video Ad Streaming Template (VAST) adavailability record.

FIG. 3 is a message exchange diagram for an example implementation.

DETAILED DESCRIPTION

A detailed description of implementations of the technology disclosed isprovided with reference to the FIGS. 1-3.

The technology disclosed addresses a niche of advertising. It isparticularly well adapted for use with the Digital Video Ad ServingTemplate (VAST) standard promulgated by the IAB Digital Video Committee,which currently is reached version 3 as of September, 2012.

A substantial percentage of video advertising fill requests gounfulfilled at present because the available video and animated adcontent is made available in formats that are incompatible with mobiledevices that request advertising fill. An ad server may, for instance,request a video ad to run on an iPhone®, only to find that the VAST adavailability record that receives identifies content in an FLV format.Since the iPhone does not support Flash decoding, the video ad cannot bedelivered.

The technology disclosed involves recognizing that the ad availabilityrecord specifies an incompatible format, transcoding the ad content to acompatible format, and streaming it from a substitute URL to a player onthe requesting mobile device. An availability record is modified beforeforwarding to the mobile device to direct the mobile device to thesubstitute URL.

Transcoding on-the-fly can be accomplished in memory, without needing tobuffer the entire video ad content. Communications between thetranscoding processor and a video display client or video player runningon the device requesting the video ad content can synchronize thetranscoding so that streaming does not begin until the player is ready.Additional communications between the transcoding processor and thevideo player can pause, restart, replay or skip the video ad content.

FIG. 1 is a high level block diagram of an example environment 100 inwhich an ad mediation server 117 adapts video ads from an incompatibleformat to one that run satisfactorily on a mobile device 155. Theenvironment 100 includes at least one mobile device 155 that includes acomputing device 156 processor and at least one application 157 runningon the processor. An ad mediation server 117 includes a mediationprocessor 118 and a transcoding processor 128. One or more ad servers130 serve up an availability record 110 and ad content 140 listed in thead availability record's 110. The environment includes a communicationsnetwork 135 that allows for communication among the various componentsof the environment. During operation, the mobile devices 155 request theso-called fill a video ad space. The ad mediation server 117 obtainsfrom the ad server 130 and at availability record. A mediation processor118 recognizes that the available ad is in a format incompatible withthe mobile device 155. The system transcodes the available ad content140 video stream using a transcoding processor 128. The mediationprocessor 118 provides the mobile device 155 with a substitute URL withwhich to access the streaming video ad content.

In one implementation, the network 135 includes the Internet. Thenetwork 135 also can utilize dedicated or private communication linksthat are not necessarily part of the Internet. In one implementation,the network 135 uses standard communication technologies, protocolsand/or inter-process communication technologies.

Mobile devices 155 execute applications 157 such as video players. Themobile devices 155 may include a tablet computer or mobile phone. Thetechnology disclosed can also be applied in environments that includeother devices with limited video display capabilities, such as connectedTVs, set-top boxes and DVD players. These devices have limitedcapabilities, in the sense that they expect to receive video in aparticular format.

The ad mediation server 117 can be implemented in hardware, firmware, orsoftware running on the hardware. Software that is combined with thehardware to carry out the actions of ad mediation 117 can be stored oncomputer readable media such as rotating or nonrotating memory. Thenonrotating memory can be volatile or nonvolatile. In this application,computer readable media does not include a transitory electromagneticsignal that is not stored in memory; computer readable media storesinstructions for execution. The ad mediation server 117 can beimplemented on a real or virtual machine running on a real machine. Itcan be implemented on one machine, cluster of machines, distributedmachines or even using cloud computing resources such as Amazon's EC2.

The ad server 130 may be an ad network, potentially supported by one ormore content distribution networks.

FIG. 2 is a sample VAST ad availability record 200. Similar adavailability records may comply with VAST version 3.0 or a later versionof the VAST family of specifications promulgated by the InteractiveAdvertising Bureau (IAB) Digital Video Committee or its successor. Theformat of a particular ad being served by this ad availability record isspecified by a URL 250. In this instance, the ad is an FLV format.

The technology disclosed transcodes the specified FLV or otherincompatible video format to a video for format usable by a mobiledevice that has requested an ad fill. It streams the transcoding advideo from a URL temporarily allocated for streaming this ad. Thetemporarily allocated URL is substituted in the ad availability record200 for the incompatible FLV URL 250. Typically, the modified adavailability record is forwarded to a player on the mobile device.Alternatively, the temporary URL could be forwarded with informationextracted from the ad availability record in a more easily processedformat, such as JSON.

FIG. 3 is a message exchange diagram for ad example implementation.While four devices are indicated as being involved in thecommunications, additional devices may be involved or a single devicemay serve multiple roles, such as one server cluster handling both adexchange and video ad source roles. In addition, other layers may beinterposed, such as a content delivery network (CDN). Those other layersare amended for the sake of clarity.

In one implementation, delivery of transcoded video ad content involvesa mobile device 301, an ad mediator 303, an ad exchange 305, and a videoad source 307. Again, devices responding to a video ad fill request maybe servers, cloud-based computing resources, workstations, etc. Forconvenience, the method illustrated is described with reference to thesystem that can be used to implement it. The mobile device 301 sends anad fill request 311 to the ad mediator 303. The ad mediator sends arequest 323 to an ad exchange 305 for video ad content. The ad exchangeresponds with an ad availability record 335. The ad mediator 303recognizes that the content specified in the ad availability record 335is incompatible with the display capabilities of the mobile device 301.It configures the transcoder to convert the available video ad contentto a format usable by the mobile device 301. It allocates a URL fromwhich transcoded video content streams. The ad mediator 303 requests thevideo ad content 343 from the specified video ad source 307. It receivesthe video ad content 357 for transcoding. The ad mediator 303 sends themobile device 301 a message 363 that specifies the allocated URL atwhich the streaming video ad content will be available. The message 363also may include information specified by an ad delivery standard suchas VAST 2.0 or 3.0.

In some implementations, one or more messages 371, 373 can be exchangedbetween the mobile device 301 and ad mediator 303 to synchronizeinitiation of streaming the transcoded video ad content. Messages alsocan be exchanged to pause or otherwise control streaming to the mobiledevice.

Particular Implementations

In one implementation, a method that fills ad space is described withvideo ads to show on mobile devices that have limited displaycapability. This method includes receiving an ad availability recordwith a source URL for video ad content that is in a format incompatiblewith a requesting device that is requesting ad content and allocating aURL from which to stream the requested ad content. The method furtherincludes responding to the request by sending at least the allocated URLand some information from the ad delivery record to the requestingdevice and automatically transcoding the ad content to a live videostream accessible at the allocated URL in a format compatible with therequesting device.

This method in other implementations of the technology disclosed caneach optionally include one or more the following features.

The requesting device can be a mobile device with a limited videodisplay capability.

The method can include retrieving the video ad content from an ad sourceserver after receiving the ad availability record.

The ad availability record can be compatible with a display video adserving template standard, abbreviated VAST. This can be any standardsin the family of standards promulgated by the Interactive AdvertisingBureau's Digital Video Committee. Two of the standards in this familyare version 2.0 released in November 2009 and version 3.0 released inSeptember 2012.

Sending can further include forwarding the ad availability record withthe allocated URL substituted for the source URL.

The method can further include exchanging messages with a video playerto synchronize the start of streaming with readiness of the player tostream. It can include exchanging messages with a video player to pauseor cancel transcoding responsive to directions from the video player.

The method can further include identifying the format compatible forvideo streaming to the particular mobile device and automaticallyadjusting transcoding parameters to match the particular mobile device.This may be extended to include identifying a change in the format forvideo streaming being used by the particular mobile device andautomatically readjusting transcoding parameters to match.

Other implementations may include a non-transitory computer readablestorage medium storing instructions executable by a processor to performone or more methods as described above. Yet another implementation mayinclude a system including memory and one or more processors operable toexecute instructions, stored in memory to perform any of the methodsdescribed above.

While the technology disclosed is disclosed by reference to thepreferred embodiments and examples detailed above, it is to beunderstood that these examples are intended in an illustrative ratherthan in a limiting sense. It is contemplated that modifications andcombinations will readily occur to those skilled in the art, whichmodifications and combinations will be within the spirit of theinvention and the scope of the following claims.

What is claimed is:
 1. A method of filling ad space with video ads toshow on mobile devices that have limited display capability, including:receiving an ad availability record with a source URL for video adcontent that is in a format incompatible with a device that isrequesting ad content; allocating a URL from which to stream therequested ad content; responding to the request by sending at least theallocated URL and some information from the ad delivery record to therequesting device and automatically transcoding the ad content to a livevideo stream accessible at the allocated URL in a format compatible withthe requesting device.